The present invention relates to the field of calendaring software, and, more particularly, to eliminating duplicate and invalid calendar items from end user calendars.
Calendaring systems are used in many contexts to assist users in maintaining their schedules. These calendaring systems often include collaboration mechanisms to expose one user's calendar to others for viewing, modifying, and/or deleting calendar entries. Additionally, calendaring systems are often used to coordinate attendance and timing of an event having multiple attendees, such as a meeting. Calendaring systems can have server side and/or client-side components depending upon implementation specifics. Either way, calendars are maintained on a user specific basis. That is, a unique user identifier of a calendar owner is associated with a calendar identifier within a data store, such as a relational database management system (RDBMS) that maintains calendar data. Each calendar entry also is associated with a unique calendar identifier, (i.e., calendar identifier is a foreign key in a calendar entry table). At present, calendar entries are not uniquely identified across multiple calendars and are only unique within a given calendar. No unique identifier for a calendar event is currently is shared among a set of calendars, each of which includes an entry for the calendar event.
A lack of a unique identifier for a commonly referenced calendar entry results in numerous problems, which include duplicate entries being mistakenly placed in a calendar and results in a calendar containing “orphan” or invalid entries. Present solutions exist that perform post-processing actions (e.g., UNDUP by STEVENS CREEK, DUPLICATE APPOINTMENT ELIMINATOR ADD-IN for OUTLOOK by SPERRY SOFTWARE, etc.). Post-processing actions attempt to determine if a calendar entry is a duplicate of another based upon meeting properties. When an original meeting is altered, the “duplicate” does not possess the same meeting properties and often will not be properly detected by a post-processing operation. Further, post processing operations do not provide calendaring applications (server-side and client-side) with leverage to coordinate changes to a “shared” calendar entry, which is implemented as an unsynchronized series of independent records stored within local calendars.
To illustrate through an example, public meetings (e.g., calendar events) can be distributed to a set of attendees via an email message. Recipients of this email message are presented with an option to add-to-calendar. Selecting this option creates a new calendar entry in the recipient's calendar database. If the recipient inadvertently presses the button more than once either due to user finger check or redistribution of the email, multiple calendar entries appear on the users' calendar for the same meeting. When a meeting is altered and is redistributed within a new email which contains an option to add-to-calendar, the original meeting entry(s) become orphans because pressing the option to add the new modified entry does not affect the original entry. When automated programmatic events (e.g., reminders, alerts, user notifications) and reports are executed based upon the redundant calendar entries, users are further mislead or frustrated by the “incorrect” notifications/reports.
An onus can be placed upon an end user to self-monitor their calendar to manually insure that redundant entries have been pruned from their calendar and/or to ensure that multiple acceptances of a common meeting are not made (e.g., selecting an accept button twice and/or accepting a meeting request for a common meeting included in different email messages). This solution is inelegant and prone to mistakes, especially when multiple users (a calendar owner, secretary, boss, etc.) have access to updating a user's calendar.
Another possible solution places a burden of including logic within a meeting request message that ensures that no existing entry exists for that meeting within the end-user's calendar before an add-entry action is performed. This solution requires a sender of a meeting requests possesses more technical expertise than many users have. Even if the sender has the requisite level of expertise (or has access to a plug-in that facilitates adding duplicate checking logic for outbound messages), most senders would not be incentivized to circumvent a recipient experienced problem that results from a “recipient induced error”. Simply put, the sender of the calendar entry doesn't generally suffer when a recipient duplicates a meeting entry in the recipient's local calendar, and may generally consider any such problems outside their scope of concern.